HTTP Adaptive Streaming (HAS) is a state of the art video streaming technique that transfers (usually temporally) chunked video over HTTP. A chunk might be referred to as a fragment (which may be stored as part of a larger file) or a segment (which may be stored as separate files). Chunks can have any duration, but are usually either 2 or 10 seconds each. Every chunk is available in one or more quality representations. This allows the client to seamlessly adapt the quality of the video from one chunk request to the next, based on current network and device conditions. The location (usually in the form of a URL) from which every chunk can be retrieved is stored in a manifest file. In Dynamic Adaptive Streaming over HTTP (DASH), the MPEG HAS standard, this file is also referred to as the Media Presentation Description (MPD).
At the start of the streaming session, the client first requests the manifest file, in order to determine the set of quality representations, the representation bitrates, and their locations. Subsequently, the client may start requesting the chunks in sequence using the HTTP protocol. The quality representation in which each chunk is requested is determined by the client's rate adaptation algorithm. In an article by Akhshabi et al. “What happens when HTTP adaptive streaming players compete for bandwidth?” Proceedings of the 22nd international workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV '12), 2012 it is described that state of the art HTTP adaptive streaming video players show different problems when multiple client devices are simultaneously streaming video over a single bottleneck link. These problems may include stability (i.e., ability to retain a specific quality level), fairness (i.e., ability to (fairly) allocate available network resources across the different streaming sessions), and bandwidth utilization (i.e., ability to utilize all available bandwidth resources).
The lack of stability, fairness, and bandwidth utilization were not caused by TCP dynamics, but rather by the typical ON-OFF behaviour of rate adaptation algorithms. ON-OFF behaviour refers to the fact that HAS client devices, when operating in a steady-state with a full buffer, go into alternating states of downloading a chunk (ON) and waiting until there is room in the buffer to download the next chunk (OFF). The ON and OFF periods of different client devices may overlap in different ways (e.g., alternating, coinciding, enveloping), which in turn affects the client-side estimated bandwidth. And it is exactly this wrongly estimated bandwidth value that negatively influences stability, fairness and utilization.
An example of a solution for problems related to competing HAS client devices is described by J. Jiang, et al. in their article, “Improving fairness, efficiency, and stability in HTTP-based adaptive video streaming with FESTIVE.” Proceedings of the 8th international conference on Emerging networking experiments and technologies (CoNEXT '12), 2012. The FESTIVE algorithm aims to improve stability, fairness and efficiency. To this end, several optimizations are proposed, such as randomized chunk scheduling, stateful bitrate selection, delayed update, and using the harmonic mean estimated bandwidth. The first optimization improves fairness by reducing synchronized bias of ON and OFF periods (i.e., the ON period overlap becomes random for each subsequent chunk). Moreover, the second optimization is applied to improve fairness by letting the algorithm wait k chunk request periods (with k the current quality level) before allowing the quality to be increased. This policy gives a higher probability of convergence to a fair state, despite the biased bitrate-to-bandwidth relationship (i.e., TCP will give a higher bandwidth share to a client already downloading a higher quality than to a client currently downloading a lower quality).
Pure client-based solutions as described above run the risk of getting stuck in local optima or converging more slowly, both resulting in reduced global and per-client video quality. For example, the client-side FESTIVE algorithm reduces the rate at which client devices improve their bitrates. This leads to slower convergence to the optimal quality, both at the start of a streaming session, as well as after a temporary drop in available bandwidth. Moreover, client-side solutions such as the FESTIVE algorithm may achieve fairness in a scenario where client devices have not yet reached a steady state. However, if a client has already received a steady state, slowly increasing their quality will not allow new client devices to obtain their fair share of the available bandwidth.
Hence from the above it follows that there is a need in the art for improved methods and systems for enabling adaptive streaming client devices to (fairly) share network resources.